Thanks @ElliotRoe! I should have time to review this weekend.

One quick thing now: make sure there are no package-lock.json updates in your branch; use npm ci to get package updates, not npm update.

Thanks so much for your detailed feedback! I will keep working on the rest of the deliverables for the issue and implement your feedback. I would expect to be in a good place for another round of feedback in about two weeks. Thanks!

Hi @amyjko. Just following up with a quick update and a clarifying question about your feedback regarding search bar alignment. I'm behind where I thought I would be two weeks ago, but have continued to make progress on the issue which I'm tracking above in the body of the PR.

In regards to your comment, "The vertical alignment of the search box should probably be baseline aligned rather than centered, since it's hard to tell that it is searching the view.", could you modify the original design Figma or give a quick sketch of what the alignment should look like? I'm not sure what you mean by this. I understand baseline is a CSS option for flex box item aligning, but changing the alignment from center to baseline puts the bar at the very bottom of the view which I'm not sure is what you intended.

I'll check in again in around two weeks! I can't promise that the PR will be in a good place for another round of feedback then, as my spare dev time is decreasing with the semester ramping up but I'll continue to chip away at the issue and track my progress above. I've been having tons of fun coding so far!

Thanks!

Thanks for the update @ElliotRoe!

I don't have access to the original Figma sketches to modify them, so I'll try to clarify here with words. Visually, I think vertically aligning the search field at the top of the container (with the recently used row), rather than aligned with the top of the emoji grid, would make more sense semantically, because the default operators and recently used emojis disappear upon search. If the default operators and recently used were persistent, even after search, then it might make more sense to vertically align it with just the grid. When I said "baseline", I was more referring to how to vertically align: ideally, the search box's baseline and the row of recently used emojis would be vertically aligned, at the top of the container.

I can add a new sketch if this isn't clear.

Gotcha, that clears it up. Thanks!

Hi! Just checking in with a quick update. I was able to chip away at most of the trivial tasks for the ticket. With the help of my wonderful labmate Grace Barkhuff, I've begun implementing a WCAG 2.2 compliant combobox for the drop-down menu. Additionally, I have also started on modifying the necessary JSON project schemas to enable the recently used feature for Firebase. I hope to have these larger features of the ticket finished by mid April. Thanks! -Elliot

Pinging here that this ticket is still on my radar! More commits will roll in this coming weekend. Thanks.

Excellent, we look forward to it!

Hello @amyjko! Combobox ui component and recently used feature have been completed. The last larger task that I need to complete is the fixing of the "other" category scrolling issues then I'll just have some final clean up and localization tasks. I'll quickly go over my recently used implementation as it has the largest design consequences that you may want to weight in on.

As you suggested, I implemented the recently used glyphs feature at the project level. I added a new array of strings as a property to the projectSchemaV2 zod schema, then modified the appropriate helper functions to account for the new property. I had two questions:

1. Will we need to version the project schemas? Right now, I just have it to default to an empty array if no recentlyUsed property is defined on the project object. Is this acceptable?
2. I wasn't totally sure where the best place to house the recently used array concatenation logic. For now it's in the GlyphSearchArea component, but I noticed a lot of event logic being handled in ProjectView.svelte. I tried to do something similar to the pattern that I saw there with svelte's event dispatcher api but for some reason it was not playing nice with the editor.edit call. I also considered handling it there, but wasn't sure if that made total sense either. Any thoughts or suggestions?

Thanks, shooting to completely finish this ticket by the end of the school year (may 5)
Elliot

Exciting progress, thanks @ElliotRoe.

• Since we're storing recently used at the project level, yes, versioning this using the pattern is right, and initializing them to an empty list seems reasonable.
• ProjectView is doing a lot right now; I think when we eventually migrate to Svelte 5 once it's officially released, this will be a lot cleaner, but for now, I'm loathe to add more weight to an already monolithic component. I think centralizing the logic around glyph usage in the search area is fine; there are many other components that encapsulate project updates already using the common global interface for updating projects. We can always refactor later, so this seems reasonable for now.

Quick update about my work on this ticket as I'd like to document my work on this sub-issue so far. I've been diving into the scrolling performance issues which is particularly seen when scrolling the "other" category because of it's large size. I've gone through several steps to localize the issue:

1. Removed the use of the VirtualList component
   • This creates a large CPU usage spike as soon as you select the "other" category then the same performance issues persist as the user scrolls through the glyphs
   • It doesn't seem like the virtual list component is the root of this issue
2. Only rendered 1 glyph at a time
   • Improves performance, which seems to indicate that complex nature of the Button and Token view components are causing this slow rendering
3. Removed TokenView component and replaced with raw string of glyph
   • Improves performance, but does not resolve issue
4. Removed Button & TokenView and replaced with raw string of glyph
   • Good performance at max scroll speed

Conclusion: It seems like the complex nature of the Button and TokenView components are causing the slow down as 100s of components must be rendered over a couple seconds at max scroll speed.

Possible Solutions

Here are some solutions I'll be exploring to fix the issue

1. Limit scroll speed
   • Issue: Doesn't feel great to limit user action in this way
2. Pause scrolling like in this example
   • Issue: Does not solve the case of scrolling back up quickly
3. Paginate the pages
   • Issue: Not in original design, scrolling seems much more intuitive
4. Lazy Rendering (e.g. render strings when scrolling & full component when not scrolling)
   • Issue: Concerned this could cause accessibility pitfalls, but not completely sure

My current plan is move forward with solution 2 and implement a way to limit scrolling back up as it seems the most simple. Of course, open to suggestions and thoughts for other solutions too. Thanks

Thanks for digging into the performance issues in detail here; scale is tricky, no matter how zippy Svelte is! (It will be getting zippier with v5, but probably not enough to address this scale).

From a UX perspective, I think following pagination conventions (options 2 and 3) seem most ideal, since they will be familiar. The only alternative would be a raw string glyph instead of interactive component, and then handing events at the container level instead of the glyph level, avoiding Button and TokenView. I'm not opposed to that if you want to tackle that. The challenge there is accessibility: every glyph still needs to be focusable and selectable, so it would probably need to implement something like the layout grid role.

Gotcha, that makes sense. I would be happy to tackle creating a lightweight scrollable component (seems super fun to build) that meet those specifications, especially if you feel that it would be useful and reusable in the larger context of the code base.

However, I'm hesitant to continue to add to the list of tasks in this ticket. I think for now I'll implement some pagination options you mentioned above. Then, open a separate ticket detailing the requirements of the light weight scroll components, if needed.

Pagination sounds reasonable for now. Thank you for the steady work on this!

Just checking in on this PR. Think you'll want to finish it up at some point?